CBOM: add protocol registry schema - #1010
Conversation
Defines protocols by family and version, alongside the existing algorithm families and elliptic curves. Each version carries a composition: a list of functional slots that all apply. A slot holds an algorithm set; "selection" states whether all, one or more, or exactly one of the set are used at runtime, and "selectedBy" how that choice is made (negotiation, configuration, ...). Set members are algorithm names that resolve against the variant patterns of the algorithm registry, or named bundles of such names (cipher suites, hybrid key exchange groups). The TLS 1.3 entry is illustrative for now; the list will be populated further. Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
Mehrn0ush
left a comment
Mehrn0ush
left a comment
There was a problem hiding this comment.
Hi,
The composition model and TLS 1.3 example make sense to me. I left a few inline questions on join semantics, pattern resolution, and selectedBy; all minor while this is draft.
One more thing I didn’t inline is: the registry looks like “what a protocol version can negotiate,” while existing protocolProperties.cipherSuites / IKEv2 fields describe this instance. A short note on that layering (and how registry names relate to IANA-style identifiers in CBOMs) would make the split clearer for implementers.
| "description": "Defines a specific protocol version and its algorithm composition.", | ||
| "additionalProperties": false, | ||
| "properties": { | ||
| "version": { |
There was a problem hiding this comment.
How should tools join this to a BOM? Is the lookup an exact match on protocolProperties.type + protocolProperties.version → family + this version string (e.g. "1.3" only)? Worth documenting, since there’s no schema $ref or uniqueness constraint on the pair.
| "algorithmSet" | ||
| ] | ||
| }, | ||
| "algorithmSet": { |
There was a problem hiding this comment.
Pattern matching isn’t enforced by JSON Schema here — only plain strings. right? For PQ-readiness queries, should there be a short resolution rule (or CI check) so bad names don’t silently fail lookup?
| "description": "The set of algorithms that can fill this slot." | ||
| } | ||
| }, | ||
| "required": [ |
There was a problem hiding this comment.
selectedBy is in the PR description and all TLS examples, but it’s not required here. Intentional, or should it be required when selection is one-of / any-of?
A member of an algorithm set can now reference another protocol by family and optionally version, so composite protocols can be expressed: IPsec selects IKEv1 or IKEv2 for key management and uses ESP or AH for packet protection. The reference is depth one; the composition of the referenced protocol is given by its own registry entry, which may again reference sub-protocols. Adds the esp and ah protocol families, an ipsec entry, and an IKEv2 entry whose slots carry the IKEv2 transform types (encryption, prf, integrity, key exchange), including ML-KEM-768 as an additional key exchange per RFC 9370. Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
The protocol type in the cryptography model now references protocolFamiliesEnum from cryptography-defs, the same way algorithmFamily and ellipticCurve do. The family descriptions move to meta:enum on the registry enum, so the registry is the single source of the protocol vocabulary, and new families (esp, ah) become valid protocol types automatically. The other and unknown values are dropped; as with algorithmFamily, an unknown protocol type is expressed by omitting the field. Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
3 participants
Summary
This adds a protocol registry to
cryptography-defs, alongside the existing algorithm families and elliptic curves. Protocols are defined per family and version, each with its algorithm composition, so tools can answer questions like "can this protocol version negotiate a post-quantum key exchange?" without every CBOM re-describing the protocol.The TLS 1.3 entry is illustrative for now; the list will be populated further (TLS 1.2, SSH, IKEv2, ...).
What's added
A new top-level
protocolsarray. Each protocol version carries acomposition: a list of functional slots that all apply together.role: what the slot does (key-exchange,signature, ...); open string with examples, likevariant.primitive.selection: how many algorithms of the set are used at runtime:all-of,any-of, orone-of.selectedBy: how that choice is made:negotiation,configuration,server-selected, ...algorithmSet: algorithm names matching the variant patterns of the algorithm registry, or named bundles{name, algorithms[]}for cipher suites and hybrid key exchange groups.Example, TLS 1.3 key exchange:
{ "role": "key-exchange", "selection": "one-of", "selectedBy": "negotiation", "algorithmSet": [ "x25519", { "name": "X25519MLKEM768", "algorithms": ["x25519", "ML-KEM-768"] } ] }Backwards compatibility
No breaking changes,
protocolsis optional.protocolFamiliesEnumuses the same tokens asprotocolProperties.type, so a BOM references a registry entry viaprotocolProperties.typeplusversion.. no new field in the core schema needed.